Day 22：自動生成架構圖，讓代理人依內文繪製流程圖 結尾留下一句話，架構圖這類流程性質圖表，今天有了明確的轉譯原則。但技術文章裡還有另一種完全不同性質的視覺需求尚未處理，統計或比較性質的數據，該如何被讀取並生成對應的圖表，這個問題今天還沒有答案，將在下一篇正式揭曉。今天要正面回答這件事。

流程圖有答案了，數字的問題還沒解

Day 22 已經把架構圖這類流程性質圖表的轉譯原則定案，統計或比較性質的數據，該如何被讀取並生成對應的圖表，這件事今天還沒有答案。今天要正面回答這件事，答案的方向分三步走，先與架構圖做對稱區隔，界定資料視覺化這個產出類型的範圍，再定案佔位符在這個情境下需要多承載什麼資訊，最後把 Day 22 的轉譯原則框架代入資料視覺化情境。

在往下走之前，先把今天的任務範圍畫清楚。今天只定義資料視覺化這一種視覺產出類型的轉譯原則，不涉及具體圖表函式庫或工具，也不涉及封面插圖生成、雙代理人協同實戰，這些留給接下來幾天處理。

架構圖問關係，資料視覺化問數字

先回顧 Day 22 定案的架構圖判準，內容本質是結構或順序關係，畫面呈現的是元件與元件之間、步驟與步驟之間如何連接與轉移。今天要沿用同一套「內容本質」判準邏輯，定義資料視覺化這個產出類型的範圍。

資料視覺化處理的是數量、比例、趨勢等可量化的數值關係，例如效能比較、時間趨勢、佔比分布這類需要用長條圖、折線圖、圓餅圖之類形式呈現的內容。

這個範圍界定，須具體說明兩者問的問題本質不同。架構圖回答的是元件或步驟之間如何連接，資料視覺化回答的是數值之間相差多少、佔比多少、如何隨時間變化。前者是關係性問題，後者是數量性問題。架構圖問的是「誰接在誰後面、誰依賴誰」，資料視覺化問的是「誰比誰多多少、佔比多少、隨時間怎麼變」，這個對稱區隔呼應 Day 22 定案的區隔判準收束句，本質是結構關係、還是數量關係、還是美術創作。

資料視覺化這個產出類型的判準也就清楚了，一段內容是否包含可辨識的、可量化的數值，以及這些數值之間是否存在比較、佔比或趨勢關係，這正是接下來要定案轉譯原則時的判斷起點。

同一個佔位符，這次要多裝一件行李

Day 22：自動生成架構圖，讓代理人依內文繪製流程圖 已經定案，系列正文裡反覆出現的 HTML 註解形式圖表佔位符，正是規劃代理人或寫作代理人為視覺代理人預留的輸入介面，格式為「」。今天要面對這個佔位符在資料視覺化情境下遇到的新問題。

架構圖的輸入完全來自文字內容裡描述的步驟與關係，靠佔位描述裡點出的節點與關係就足以完成輸入。但長條圖、折線圖、圓餅圖這類圖表如果沒有實際數字，根本無法畫出來，這是資料視覺化這個內容類型天生的需求，架構圖不需要面對這個問題，因為架構圖畫的是關係而非數值。

今天正式定案，這個佔位符除了描述呈現什麼之外，還需要額外承載數據本身從哪裡來這個資訊。這不是另立一套全新的輸入機制，而是同一個佔位符輸入介面在資料視覺化情境下需要多承載的一類資訊。舉例來說，一段描述效能比較的佔位符，除了寫出要比較哪幾個項目之外，還須點出這些數字是引用自知識庫裡的哪一段原始素材，或是正文裡哪一句話已經提過的數字。

佔位符的角色沒有變，依然是視覺代理人的唯一輸入介面，只是資料視覺化這個內容類型天生需要多帶一件行李，也就是數據來源。

數字從哪裡來，視覺代理人不能自己編

佔位符需要多承載數據來源這件事定案之後，緊接著要回答，這個數據來源具體允許是什麼形式。今天要具體定案，資料視覺化情境下佔位描述所承載的數據來源，只能是以下兩種合法形式之一。

第一種，引用自知識庫切分單元裡的原始數據段落。Day 07：知識庫的切分藝術，保留程式碼與上下文的完整性 定案，知識庫切分單元的定義是，知識庫雛形被切分後、供 Agent 檢索引用的最小單位。如果知識庫切分單元裡本來就存在包含具體數字的原始素材，這些數字可以被引用進佔位描述作為圖表的數據依據。

第二種，文章正文裡已經提過的具體數字。寫作代理人在正文裡已經明確寫出的統計數字或比較數字，這些數字本身已經是既定內容，佔位描述可以指向這些已經出現過的數字作為圖表依據。

除了這兩種形式之外，今天要明確定案一條紅線，視覺代理人不得自行編造或估算數據。不能因為佔位描述裡缺少明確數字，就自己推算或杜撰一組看起來合理的數字去畫圖。舉例來說，視覺代理人讀到一則要求呈現三個方案效能差異的佔位描述，合法的做法是回頭核對知識庫或正文裡是否已經有這三個方案的實測數字，不合法的做法是視覺代理人覺得三者應該差不多、自己抓一組數字湊出圖表。

這條紅線的性質，與 Day 21：為什麼技術文章需要圖表，視覺代理人的定位 定案的視覺代理人不判斷論述邏輯、不修改正文這條既有邊界性質一致，都是明確禁止視覺代理人越權對內容本身做出任何判斷或補充，這次落在數據真實性這個面向上。若佔位描述裡缺少可用的數據來源，這種情況下該如何處理，不在今天的討論範圍內。

圖表呈現的每一個數字，都必須有真實出處可以回頭核對，這是資料視覺化這個產出類型能否被讀者信任的地基。

同一套轉譯原則，換一種內容代入

範圍與數據來源都定案之後，今天要沿用 Day 22 已定案的三層轉譯原則框架，判斷依據、轉譯輸入、轉譯輸出，代入資料視覺化情境具體展開，不另立一套全新框架。

第一層，判斷依據。視覺代理人如何判斷一段內容適合轉譯成統計或比較性質圖表，依據是佔位描述裡是否點出可量化的數值關係，例如幾個項目之間的數量比較、某個指標隨時間推移的變化、幾個選項各自佔整體的比例。

第二層，轉譯輸入。視覺代理人讀取的是佔位描述裡已經點出的呈現需求與數據來源這兩類線索，不是自己重新閱讀通篇正文去尋找或推算數字。這一點呼應 Day 21 定案的輸入是已經存在的文字或數據。

第三層，轉譯輸出。視覺代理人產出的圖表必須忠實呈現數據來源裡的實際數字，不能自行增減數據點，不能自行調整數值大小。這一層明確扣回前一節定案的不得自行編造或估算數據這條紅線。

判斷依據、轉譯輸入、轉譯輸出這三層框架，Day 22 用它定義了架構圖的轉譯原則，今天用同一套框架定義了資料視覺化的轉譯原則，代入的內容不同，但框架本身沒有變。至於這個轉譯過程具體要用哪一種圖表函式庫或工具產出最終畫面，今天不指定，交由實作時依當下條件決定，這與 Day 22 不規定具體要用哪一種繪圖語法或工具的原則層級論證方式一致。

圖表都有答案了，畫面呢

今天正面回答了 Day 22 留下的伏筆，統計或比較性質的數據該如何被讀取並生成對應的圖表，這件事今天有了答案。

資料視覺化的範圍今天劃清楚了，沿用 Day 22 定案的「內容本質」判準邏輯，處理的是數量、比例、趨勢等可量化的數值關係，與架構圖處理的結構或順序關係對稱區隔，架構圖問的是元件或步驟之間如何連接，資料視覺化問的是數值之間相差多少、佔比多少、如何隨時間變化。

今天最重要的定案，是圖表佔位符依然是視覺代理人唯一的輸入介面，不是另立一套新機制，只是在資料視覺化情境下，這個佔位符除了描述呈現什麼之外，還需要額外承載數據本身從哪裡來這個資訊。數據來源只能是兩種合法形式，引用自知識庫切分單元裡的原始數據段落，或是文章正文裡已經提過的具體數字，視覺代理人不得自行編造或估算數據，圖表呈現的每一個數字都必須有真實出處可以回頭核對。

判斷依據、轉譯輸入、轉譯輸出，Day 22 定案的這套三層框架今天成功代入資料視覺化情境，判斷依據是佔位描述裡是否點出可量化的數值關係，轉譯輸入是佔位描述裡已經點出的呈現需求與數據來源這兩類線索，轉譯輸出必須忠實呈現數據來源裡的實際數字，不自行增減、不自行調整數值。

架構圖與資料視覺化這兩類忠實轉譯既有內容的圖表，今天都有了明確答案，但技術文章裡還有另一種完全不同性質的視覺需求尚未處理，封面與插圖這類偏向美術創作性質的視覺產出，該如何處理，這個問題今天還沒有答案，將在下一篇正式揭曉。